Manage outsourced projects

This is true for any project, but particularly for outsourced ones. Widely separated work spaces for users, developers and support staff, different e-mail systems and, in the case of offshore developers, different languages and cultures, mean that you have two tough decisions to make at the assignment’s outset. One is about the effectiveness of project communications: are your current tools enough, or do you need better ones with greater capabilities?

The other decision regards project management processes and tools. For large-scale and outsourced projects, you’ll need a project plan containing a list of baseline requirements; prototypes of UI components and output deliverables; and Gannt and project charts/reports showing milestones, schedules, and resource allotments.

Give toolkits more control
Try making the process management toolkit the primary controller of outsourced projects. The new toolkits go way beyond the old project schedulers. They consist of several integrated components that address a number of project planning and control issues (see Table 1). Process management toolkits are a good controlling choice because they’re enablers—they won’t do the process planning or guarantee that exception reports will be filed properly, but their components will make these tasks much easier. And the data can always be integrated back into a multi-project, enterprise-wide summary if required.

A good project management component doesn’t simply contain a detailed version of the plan; it can actively control the project. For large or outsourced projects, a project management component’s tracking capability can prove a tremendous asset: its records of milestones, schedules, and resources form the baseline contract with the outsourcer.

And process management toolkits can be quite versatile. They can display in condensed format or in full details, in tables or customized reports. A wide range of charts and diagrams can provide precise snapshots of where a project is and where it’s going—and then deliver these messages by mail, print or Web. Think of the new project software as process management toolkits designed for this express purpose.

The majority of crucial risk factors for IT projects involve not having project schedules and resources or tracking them adequately. As someone who is expected to track project schedules and perform ongoing risk assessments, you’ll have to draw from project templates and process estimators. The scoping stage is critical to identifying risky phases within the project—an implicit part of your troubleshooter mandate.

Information is power. If the members of your team see you as instrumental in keeping project schedules and information timely, your implicit authority and power will only grow as the project unfolds.

Bring in the Web for better communication
Project management tools have moved well beyond Gannt charts and PERT diagrams. The new tools are really process management toolkits. They offer four capabilities beyond excellent GUI-based project and resource scheduling:

• Tighter integration with system requirements and process estimation tools.
• Components to quickly handle multi-project, organizational project portfolio views.
• Components to use time, resource, and cost data, which directly reduces expensive repetitions.
• Multiple modes of output delivery via e-mail, file, printed reports or Web pages.

Web-based report delivery is vital to project communications, especially across corporate boundaries in an outsourced project. Indeed, Web delivery has proved so popular and cost-effective that many developers are starting to offer project input such as costs, timesheet and activity alerts and reports through Java or Web front ends.

Most project planning tools are based on server-side databases acting as repositories for plans, schedules, and resource data. This client/server design allows for better integration with ERP and other existing cost and accounting systems, eliminating one major defect of desktop project planners—poor integration, which forces redundant and error-prone time/cost data entry. At the same time, the basic underpinning for multi-project and multi-resource scheduling has been put in place.

The result is that almost all of the new tools provide organization-wide project portfolio views (see Figure 1). So if you’re trying to get an adequate process management toolkit on board and all else fails, appeal to the development manager’s, CIO’s, or CFO’s compulsion to see and manage his or her entire bevy of projects.

You’ve got the tools—now use them
None of this tool-talk should imply that your job as project manager will be a piece of cake once you’ve found the right widget (just wait for Widget 2.0). The going is still tough, but it helps to have a clear idea of your own role in the project and the parameters of your obligations.

In this era of technical and managerial staff shortages, you’ll likely encounter situations where you have to act as system liaison or coordinator between internal clients and outsourcers or consultants. And if you’re really “lucky,” the position will turn out to be one of great responsibility with no authority: plain old project troubleshooter, also known as flak-catcher.

As someone who wants to sleep at night and retain some semblance of sanity, you want to be armed and perceived as competent if not dangerous. You need to understand the risks and the leverages—the control points that you have available for helping to keep the project on course. As the project unfolds, your role will change from planner to business process mentor to scheduler to troubleshooter to project champion. But throughout the project you should retain one consistent role: honest broker.

As honest broker, you provide information on a range of issues: what’s coming next, which users are authorities on different aspects of the project, when the next phase can realistically start up, and so on. You will not only be the contact point for getting consultants and users together, but will also be expected to keep abreast of the latest project status information. Because you will be constantly coordinating and scheduling the use of organizational manpower (when you’re not standing in for it), resource management is going to a big part of your game.

Not to give away the surprise, but you’ll need to determine two things the moment your assignment falls in your lap. First, find out who’s responsible for setting up project e-mail/exception reporting and process management software. Second, find out who’s responsible for running it. The answers can determine whether you want to take on the assignment.

CMM won’t really help you
Let’s take a moment to review what some distinguished observers of the software development scene have to say about why IT projects fail. Be warned: some of these descriptions of IT development are graphic and brutal.

The Software Engineering Institute estimates that nearly 70 percent of IT groups are not at CMM (Capability Maturity Model) level 2—they don’t have tools and processes in place to repeat past successes or avoid past failures. So in dealing with outsourcers, assume their CMM level is abysmal at best. Don’t bother asking what level they’re at; instead, ask some of their developers a few questions. What processes and tools are in place for handling defects and change requests? What quality assurance and testing tools do they use? This information, along with the people assigned to your project, will give you the best assessment of the quality of the outsourcing team.

At the same time, keep in mind that often it’s your own IT members and organizational staffers who are a part of the problem. Nonetheless, you are the project’s champion and facilitator. So while you’re waving the pompoms for your outsourcers, be sure to root for the home team as well.

Combat risks with ample preparation
It’s a fundamental law of IT: the bigger the project, the more likely its failure. Fred Brooks knew it in the late 60s and early 70s; Capers Jones confirmed it in his books on applied software measurement; and now the Standish CHAOS reports agree. Capers Jones showed in the late 80s and early 90s that nearly 50 percent of large systems projects failed (that is, were not delivered or not used), in comparison to about 30 percent of medium-sized projects.

So here’s another, even more interesting law of IT: the smaller the development team, the more likely the success of the project. In Software Project Survival Guide, Steve McConnell multiplies the chance of project success by 50 percent if there are three or fewer full-time developers assigned to a project. The idea falls neatly in line with the famous Brooks Corollary: neither adding people nor control processes to an out-of-control project will bring it under control.

Keep these observations in mind when considering the following IT project risk factors:

• Creeping user requirements.
• Unrealistic phases in project schedule.
• Inadequate cost and/or resource estimates.
• Poorly defined requirements.
• Mismatch of tasks to developers experience and training.
• Unstable tools.
• Early delivered components are low in quality.
• Turnover in project stakeholders.

Of course like every family, every project is unhappy in its own unique ways. But as a project moves from requirements to detail design, assessing the risks and identifying the unresolved defects are crucial. Planning and control processes should be commensurate with the project’s assessed risks. This is your point of opportunity. Be prepared as chief coordinator, troubleshooter, and flak-catcher to insist on having the right processes and tools in place to manage those risks.

It’s the vision thing
As you read the experts and talk with project leads and developers, a group of critical factors constantly rises to the top:

• Does the project have a clear and unambiguous statement of mission and vision?
• Do all the project stakeholders understand and believe in the mission?
• Does the project have a real business case that justifies costs with realistic/believable estimates of benefits?
• Does the project have a clear, detailed specification of its deliverables and how they will be made/achieved?
• Does the project have some easy mechanism for all stakeholders to keep up to date on project status, particularly information relevant to them?

As one project leader at the PLC (Project Leadership Conference) described it, “if you cannot communicate and sustain the project’s vision, the technology doesn’t really matter.”

Defining and communicating the vision of a doable plan is crucial to IT success. Getting stakeholders on board and moving in the same direction defines how to sustain the vision.

Some people argue that process and project planning systems are dictatorial, imposing their requirements on users. The new tools are flexible in two ways. First, they offer more ways of integrating data from legacy sources or delivering output onto preferred Web, mail or print targets. Second, they can be readily customized to track and deliver as much detail as is required by the inherent risk in that phase of the project. Project management is pragmatic, not dogmatic. Come up to speed with what’s available in the new process and project management tools.

Jacques Surveyer is a consultant and writer who does Web development in Toronto. He will chat about BI, Web and system development at his Website www.inforamp.net/~jbsurv.

---

© 1999 FAWCETTE TECHNICAL PUBLICATIONS, all rights reserved.