An outsourced project is out of your hands, right? Well, no, not entirely. In fact, that belief is a common misconception that can lead to trouble.
Until the contract is signed, outsourcers and systems integrators are often vague about the amount of resources that you the buyer will have to provide to assure a successful project. Many organizations, particularly small and mid-tier ones without much experience, believe that the vendor will take complete responsibility for implementation and transition to the new services. Even large organizations sometimes are placated by assurances that project execution will require little support from their staff.
Such assurances are not necessarily ill intentioned. Rather, outsourcers and systems integrators can underestimate the degree to which they need support from the customer's staff. Even when potential customers explain that their current technology base is old, complex and poorly documented, vendor sales teams are typically optimistic about the effort required for implementation and ongoing operation.
As the buyer, you need to be prepared. During contract negotiations, require the supplier to estimate the amount of time needed from your staff. Although the vendor's representatives will protest that they have not yet built a detailed work plan, they should have enough experience to provide a rough estimate and allow you to begin designing your project team.
Keep the following guidelines in mind as you do that:
- Staff the critical roles. At a minimum, every buyer's project team needs a project manager, a business analyst, a corporate communicator and a subject matter expert. In larger projects, more than one person will be needed for each role, while in smaller ones, one person may have to take on several roles.
Even if the vendor's project manager is highly competent, you need your own, experienced project manager to verify that the project plan is complete, realistic and being followed. Moreover, during the project, you need someone who places your organization's interests ahead of the vendor's when trade-offs are required. And make your project manager a peer to the supplier's project manager. Although the supplier's project manager probably will have more experience within the scope of the particular project, your project manager has organizational creditability. Don't make the mistake of having your project manager report to the supplier's project manager. This usually damages your project manager's confidence, autonomy and sense of value. More importantly, it limits your employee's ability to negotiate with the supplier.
Subject matter experts are valuable for their understanding of the subtle effects of current processes, particularly outside of IT. Politics and personalities always come into play, and it's helpful to have someone who understands the history when analyzing current processes and preparing to design new ones.
Business analysts from inside the organization will live with the new system and are therefore more motivated to make sure new operating processes provide the best support possible. They are also more likely to spot design flaws, since they are familiar with the intricate connections between the new system and existing systems.
Good communication across the enterprise is critical. No matter how well a project is managed, if the organization hears nothing, the worst is often assumed. Good communication, on the other hand, builds internal enthusiasm and momentum by celebrating project successes. Communicators should be able to explain trade-offs made during the project and should promote the endeavor over the long term.
- Embrace the culture. Every organization has informal networks that cross business units, business functions and organizational levels, thereby influencing decision-making. Project team members need to be well integrated into these networks to speed decision-making during critical project challenges.
- Backfill team members. Evaluate the workload of each person assigned to the project to make sure that no one is unrealistically overloaded, and assignments should be adjusted accordingly. This will be fairly straightforward with IT staff, whose workload should be well understood. It will be a different story with non-IT subject matter experts. Most importantly, make sure that their managers understand that these employees should be released from other duties while the project is in progress. Then backfill as necessary, before your employees (understandably) fail to reach expectations.
It should also be noted that non-IT employees are usually unfamiliar with project-oriented work. They might worry that they will not have a job when the project ends. Make it clear that at project's completion they will still have a job, and possibly even a better one. I say this because significant projects require the best people, ones who are considered critical by their department. Obviously, you would not want the enterprise's new environment to be analyzed and designed by your workforce's slugs.
Even if the vendor promises to take complete responsibility for the project and deliver the final product unaided, it is in your organization's best interest to form a joint team with the supplier. Active project involvement helps your organization own the final results and identify problems as they occur.
Decisions made during such projects will have a major impact for years, so don't wait until the project is in trouble before assigning the appropriate staff. Invest the necessary resources in your project team from the start.
Bart Perkins is managing partner at Louisville, Ky.-based Leverage Partners Inc., which helps organizations invest well in IT. Contact him at BartPerkins@LeveragePartners.com.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.