Set the Direction
As discussed in Chapter 16, the partnership model enables you to align your strategy with that of any partner or vendor by defining your own vision; developing a business case that includes the expected cost and benefits of purchasing the desired software and/or services; and defining the scope of your project. As you begin defining your business requirements, you begin to work jointly with your partner or vendor to merge both visions into one project.
Experienced project managers know that the best way to collaborate with vendors is to develop your own vision, becoming clear about your requirements before engaging the vendor. This positions you to continually drive the project yourself, from start to finish. Understanding your business needs, your options for meeting those needs, and deciding where vendor software fits into your overall scheme is the key to staying in the driver's seat.
Identify Solutions and Solution Providers
Chapter 16 covers vendor selection in detail. After you have set the direction, you can identify vendors and begin to interview them. You don't have to do an exhaustive search. Check out the literature online, ask colleagues for referrals, and discuss your needs with others who have faced similar situations. Figure 17.1 shows a process for selecting products and vendors.
Figure 17.1. The vendor product selection process depicts a process you can follow for selecting a product or service from a vendor.
As opposed to traditional sequential processes, this approach systematically uses, reuses, and refines requirements and all relevant information. The process defines “just enough” requirements to screen the market for potential solutions. The information that becomes available as a result of screening, in turn, influences and enhances the next level of requirement definition.
The first cut of your requirements is defined on the basis of the following analysis:
Current processes
Experiences with the product in other organizations
Competitive products
It is understood that today's market offers a wide array of products and services, all of which may adopt different underlying philosophies and approaches. Open technologies give users a choice of implementation among tools, methods, and techniques, as opposed to closed technologies, which are already integrated with a predefined suite of products.
First, you will select the product that seems to offer flexibility, range, and customization opportunities combined with the state-of-the-art presentation. This product will be brought in on a trial basis. Pilot projects are identified, product is installed, and introductory tutoring is offered to pilot project managers. Consulting should be provided on an as needed basis, as the pilot project managers are getting more familiar with the product.
In the beginning of your explorations, you should be able to start narrowing the field down to the two or three top vendors. Contact these top contenders and start asking questions. You might decide to download an evaluation copy of software or meet with the vendor for a face-to-face discussion. As you work through your evaluation, pay attention to the following factors:
Responsiveness to your requests, calls, and queries. Does the vendor return your calls in a timely manner? If they promise to send information, is it forthcoming? These are good indicators of how you can expect to be treated down the road—after you've signed on the dotted line.
Organizational fit. How comfortable are you with their style? Do they rub you or your staff the wrong way? Or do you get the sense that they understand your point-of-view?
Who's driving whom? You want a relationship of give and take, where there is a comfortable balance between your need to give direction and the vendor's provision of advice and consultation. Beware the vendor who offers a one-size-fits-all solution.
Meanwhile, changes on the market are monitored and analyzed to ensure that another candidate would be identified quickly in case of dissatisfaction with performance and offerings of the first selection. (In such a case, familiarity with the initially selected product by several of your people would serve as an asset for the next iteration.) In this process the requirements are finalized and an understanding of the adequacy of the product is formed. Based on this acquired knowledge, future recommendations are formulated.
Work Through Requirements and Project Planning
When you hire a vendor, one of the benefits you purchase is their prior experience and knowledge gained from implementing similar projects. An experienced vendor should be able to provide resources such as the following:
Templates for project planning
Sample deliverables
Team roles and responsibilities
Team skills required
Hardware/software requirements
Production task list
Select a Pilot or Prototype Project
One of the first steps to take with your vendor is to select a project that can serve as a pilot or prototype for proving out how the product or service will work in your environment.
Pilot projects use iterative development and prototyping to drive out requirements and deliver proof of concept early in the development cycle. With this approach, the requirements for the final product do not have to be cast in stone early in the life cycle.
Prototyping allows for effective management of risk (both technical and business), and verification, validation, and testing of requirements early in the development cycle. Figure 17.2 shows the life cycle of a typical pilot or prototype project.
Figure 17.2. The Pilot Prototype Project life cycle shows the project from initiation to product delivery.
The pilot or prototype project has a life cycle that starts with project initiation, then rapid development of the solution and rapid delivery.
Typical Pilot/Prototype Project Description
The typical project that would be suitable for a pilot has duration of from three to six elapsed months (from the start of the project to delivery). It should be long enough to allow some time for exposure to the product or service in question, but not so long as to keep the overall project from proceeding. The actual effort required by the project may vary from 3 to 15 effort-months, though for scheduling purposes elapsed time is the more significant number.
The team assigned to carry out the project should be highly skilled with knowledge of the business processes to be supported.
Risks
The risks of taking a pilot/prototyping approach include the following:
Endless prototyping spirals where the prototype never reaches completion due to continually changing requirements.
The prototype escaping into production. This happens when there is strong pressure from the business to implement the prototype because it looks like it meets their requirements. Often in this situation the system implemented would be poorly documented, have poor performance, and be difficult to maintain.
Lack of the user involvement required to ensure success. Although the necessary user involvement will vary depending on the particular project, expectations should be established up front and be tracked. The frequency and average duration of user requirements sessions or interview and review processes must be defined. It is important to gain agreement that the business partners involved will be empowered to make decisions for their area and that these decisions will be supported after the sessions/reviews.
Continually expanding scope— known as scope creep, the temptation to keep adding one more requirement can be a liability.
Frustration from the business because they cannot understand why it takes so long to complete a system when the prototype appears to be a completed application.
Risk Management Factors
Established during project initiation, a detailed specification of the scope of the prototype must be defined, including expectation setting in terms of what will not be included. In order to manage the risks inherent in the pilot/prototyping approach, the following rules must be observed:
The level and types of business involvement must be defined. Expectations must be set up front and tracked.
The frequency and average duration of business user interview and review processes must be defined.
Agreement that the business partners involved in interview and review will be empowered to make decisions for their area and these decisions will be supported after the reviews.
Agreement to the principles of time-boxing, that is, that the deadline will be met even if that means cutting functionality.
Evaluate Results
Your product evaluation pilot project will yield useful information and increased experience whether you decide to continue to a full implementation or not.
Results can be delivered formally or informally, and should include the following variables:
Functional usefulness. How well did the product or service meet our business requirements?
Quality of service. This includes responsiveness, attention to detail, flexibility, and ability to respond quickly.
Architectural fit. How closely does the product architecture fit our selected framework?
Business architecture. How well do the embedded business models reflect our desired way of doing business (for example, in a CRM application, the architecture of the customer model is very important).
Recommendations for going forward. To proceed or not and how to fine-tune the implementation, based on the experiences of the pilot (for example, increased attention to user training, speeded up schedule because of ease of use, and so on. )