Overview of our Methodology for developing world class solutions.
Discovery
Initial assessment is no small task, and should be given every bit as much consideration as any other stage of the project. While you-- the client-- usually have a pretty good idea of what you're looking for, it can take the consulting team a good deal of work to understand the internal project language and all the unsaid design goals. Corporate culture can be the enemy of a successful project if you're not careful, because all those things you take for granted as "the way things are" may be unknown to your consultants.
In our model, we ask the client to agree to a small, fixed cost set of discovery tasks that culminates in a detailed requirements specification and more complete cost estimate. There are two distinct deliverables, first is the requirements and implementation plan. This makes no mention of cost, and has value in its own right as a road map to the completed project. The second deliverable is a quote for the implementation of that plan, and includes the information the client needs to understand the cost and time involved in implementing the project. This is almost always done on a short duration fixed cost basis, allowing the client and consultant to build a mutual understanding of the tasks at hand, and the capabilities of both teams.
Development Phase
The Development Phase is usually where the bulk of the time is spent. It is the implementation of the project plan developed in the Discovery Phase, up to the point where the application is feature complete according to the initial specification, plus any mutually agreed changes that have been accepted by both the client and the consultant. This phase can be billed on a fixed price or Time and Materials (T&M) basis. The decision on the type of billing largely depends on how well scooped and defined the development effort can be.
This is the client's first real exposure to the application and, like it or not, it will produce change orders. Any misconceptions or omissions from the discovery phase will be most apparent here. By using the Extreme Programming teams with direct customer contact, we hope to reduce the errors that occur from miscommunications. The team will comprise of 1 to 3 developers along with a customer representative. The customer representative should have a good knowledge of the business side of the application so he can make decisions on the usability of the applications. The goal is to deliver the application in small definable deliverables that can be tested and validated. These deliverables are defined during the discovery phase. This method of development allows the customer to see the progress without the overhead of a Project Manager.
Unit Testing Phase
This phase is where those projects that get into trouble really begin to show the signs. Often, the client feels that many things should have been done in the development phase and is reluctant to pay for them in this phase. At the same time, the consulting organization often feels that the customer is taking advantage of the "bug fix" nature of this phase to change or add functionality. By using the Extreme Programming method it will be the Teams duty to decide if that is a bug or added functionality and if the solution is cost-effective for the loss or added functionality. These decisions will be presented to management when ever they cause an impact to the cost or functionality of the applications.
Deployment
Deployment tends to be a fixed cost, one-time expense. Handling this correctly is critical and must be carefully planned. Additional support resources are often required during the deployment phase. A good, well planned deployment phase with the right level of support and training can mean the difference between success and failure for the project in the long term. For most users of the finished project, the deployment phase is their first contact with the highly anticipated new tools.
Documentation
Documentation tends to be fixed cost, but its scope should be clearly agreed on in advance. A predefined set of expectations must exist. The target audience is a critical consideration. Documentation meant for end users in a "How-To" format is vastly different from -- and does not replace the need for -- technical documentation on the structure and design of the deliverable.
Support
Support is the most complex part of the rollout process. For support to be successful, here are some things that must be considered:
* Note that the customer should be able to set the priority using these specific guidelines, but should not be tied to the guidelines absolutely.
(a) Agreement on the assignment of priority -- Priority should be determined primarily by the specific conditions, for example:
- large number of users unable to do their job
- critical application function failure
- some users unable to do their job
- secondary application function failure
- look and feel issues
(b) Service Level Agreements must specify
- minimum call back times
- minimum time to a plan for the resolution of issues
* Note that a commitment to a resolution plan simply means that a plan will be in place to resolve the issue. You cannot guarantee absolutely to have a problem solved in a specific time until you know what the problem is.
(c) Support Costs should be variable based on the priority set by the customer. This can take many forms, but most often it means that if a customer ignores the guidelines and assigns a higher priority, there is some cost associated with that.