Managing Project Commitments | E-Commerce Security: Advice from Experts (IT Solutions series)

< Day Day Up >

To put it simply, any IT activity that is not covered through an SLA is a project that must be assigned IT discretionary resources. The author takes it as a given that the enterprise employs a planning process of some type whereby IT projects are identified and prioritized. (See Chapter 3 for a detailed consideration of overall IT organization planning, prioritization, and resource alignment.) IT is then asked to proceed with this list, in line with available resources. Once the business has sorted out what it plans to do for the year, the information technology organization must have in place its own process for governing the system development life cycle (SDLC) for each approved project. This process will address all new IT work, as well as those few system or Web site enhancements that are greater than the SLA cost threshold for such work. Typically, project work will entail the purchase costs of new system or Web site hardware and software, as well as internal and external labor costs, initial product licensing, and so forth. It is also standard practice to treat as project costs maintenance and support costs incurred during the life of the project and through the remainder of the first fiscal year of its delivery. Once a project deliverable is in production, its ongoing cost is added to the appropriate SLA for the coming year of service delivery.

All of this sounds straightforward. Unfortunately, IT organizations find it much easier to manage and deliver routine, ongoing SLA services than to execute projects. The underlying reasons for this state of affairs may not be obvious, but they are easily summarized. Services are predictable events, easily metered, with which IT personnel and their customers have considerable experience and a reasonably firm set of expectations. More often than not, a single IT team oversees day-to-day service delivery in a particular area of technology (e.g., network operations, Internet services, e-mail services, security administration, and so forth). Projects, on the other hand, typically explore new territory and require an IT team to work on an emerging, dynamic, and not necessarily well articulated set of customer requirements. Furthermore, most projects are by definition cross-functional, calling on expertise from across the IT organization and that of its business unit customers. When many hands are involved and when the project definition remains unclear, the risk of error, scrap, and rework are sure to follow. These are the risks that the project commitment management process must mitigate.

From the outset, it must be stressed that, like the SLA process, the effort and rigor of managing project commitments will vary from one organization to another and from one project to the next. The pages that follow provide a framework for informed decision-making by the enterprise's business and IT leaders as they define, prioritize, shape, and deliver IT projects. The desire to pursue best practices must be balanced with the real-world needs of delivery within a particular business environment. (See Chapter 5 for a more detailed consideration of project management, measurement, and reporting tools.)

As a first step, the enterprise's business leadership will work with IT to identify appropriate project work. Any efforts that appropriately fall under existing SLA agreements should be addressed through the resources already allocated as part of nondiscretionary IT funding for that work. Next, each CRE will work with his or her executive sponsor(s) to define and shape potential project assignments for the coming year. Although each CRE will assist in formulating and prioritizing these project lists, he or she must make it clear that this data-gathering activity in no way commits IT. Instead, the CREs will bring these requests back to IT executive management, who will in turn consolidate and rationalize these requests into an IT project portfolio for the review and approval of the enterprise's leadership. ^[9] This portfolio presentation should indicate synergies and dependencies between projects, the relative merits and benefits of each proposal, and the approximate level of investment required and risks associated with each proposed undertaking.

With this information in hand and as part of the annual budgeting and planning process, the enterprise's business and IT leaders will meet to prioritize the list and to commit in principle to those projects that have survived this initial review. Typically, all enterprise-level projects emerging from and funded by this process are of the highest priority in terms of delivery and resource allocations. If additional resources are available, business unit-specific projects may be considered in terms of their relative value to the enterprise. In the for-profit sector, enterprises will define a return-on-investment (ROI) hurdle rate for this part of the process, balancing line-of-business information technology needs against overall enterprise IT needs. In many instances, business units may receive approval to proceed with their own IT projects as long as they can fund them and as long as internal IT has the bandwidth to handle the additional work. Invariably, unforeseen circumstances and business opportunities will necessitate revisiting the priority list. Some projects may be deferred and others dropped, in favor of more pressing or promising IT investments.

Similarly, as the IT team and its business partners work through the development life cycle on particular projects, they will find that their original assumptions are no longer valid, requiring the resizing, rescheduling, redefinition, or elimination of these projects. The key to success here is the employment of an initial, rigorous project-scoping effort, coupled with a comprehensive project life-cycle management process that ensures regular decision points early in the project's design, development, and implementation phases. Once a project is properly scoped and enters the pipeline, the IT project director, ^[10] working in collaboration with his or her working client(s) and supported by an IT project manager, ^[11] will create a commitment document and a project plan (both to be discussed later), reflecting detailed project commitments and resource allocations. The IT CRE will then monitor the project team's overall compliance with the plan, reporting to the customer on a regular basis.

Initial project scoping is key to the subsequent steps in the project management process. All too often, projects are pursued without a clear understanding of the associated risks and resource commitments. Neither the project's working clients nor its IT participants may understand their respective roles and responsibilities. Operating assumptions are left undocumented, and the handoffs and dependencies among players remain unclear. Without sufficient information along these lines, IT efforts so undertaken will usually end in severe disappointment. To avoid such unhappy results, IT project teams should embrace a commitment process that ensures a well informed basis for action.

From the outset, no project should proceed without an executive (business) sponsor and the assignment of at least one working client. The executive sponsor's role is to ensure the financial and political support to see the project through. He or she owns the result and is therefore the project's most senior advocate. The sponsor's designated working clients are those folks from the business side of the house who will work hand-in-hand with IT to ensure a satisfactory delivery of the project. Without this level of commitment from the business, no project should proceed. It is best that the sponsor appoint appropriate working clients, making it clear that they have as much at stake in the success of the project as their IT counterparts. On the other hand, avoid assigning working clients as project directors or managers. ^[12] Although these folks have the business knowledge essential to the project's success, they often lack the requisite skills to manage the coordination of IT resources and delivery. If the project in question happens to be sponsored by IT itself, then the chief IT executive will serve as sponsor and the IT manager who will own the system or service once it is in production will serve as the working client. Although it is assumed that the project is funded, the commitment document should indicate the project's recognized priority. The overall process must also capture information concerning the project's scope, the definition of delivery and associated customer satisfaction metrics, project risks, the roles and responsibilities of the project team, and so forth.

Unfortunately, many of the skills required to draw out this information from IT customers do not typically reside in IT line managers. These people focus, day in and day out, on the 24/7 availability of IT and may lack both the intimate business process knowledge and the people-management skills required to succeed in project delivery. Chapter 2 will address this subject in more detail as it justifies the creation of a formal or virtual project management office (PMO) within the information technology organization. For now, it suffices to close with the observation that, like the SLA process, project management requires its own unique portfolio of skills and tools. In particular, customer (i.e., sponsor and working client) management must complement process, risk, and resource managements. In terms of the IT organization, the CRE facilitates, coordinates, and communicates between the business and IT teams. But the CRE role is not designed for day-to-day oversight of detailed project implementation. This work rests with project directors, project managers, business analysts, and other IT personnel assigned to each project. As Chapter 2 shows, the PMO may serve as the ideal instrument for ensuring the success of these more granular efforts. As part of this work, each project team must agree on benchmarks for success: what is to be measured, how it is to be reported, and when communication is to take place. The simplest of formulas works here: report regularly, use the customer's language and metrics, and always tell it like it is.

^[9]It is essential that the business and not IT rule on project priorities. However, this does not abdicate the IT team's responsibility to consolidate and leverage IT requests that, in its view, bring the greatest benefit to the enterprise, and to identify infrastructure and other IT-enabling investments that are a necessary foundation for business-enabling IT projects.

^[10]The project director is the IT party responsible for project delivery and the overall coordination of internal and external information technology resources. He or she will work hand-in-hand with the customer working clients to ensure that project deliverables are in keeping with the customer's requirements.

^[11]The IT project manager is staff to the IT project director. This support person will develop and maintain project commitment documents and plans, facilitate and coordinate project activities, carry out business process analysis, prepare project status reports, manage project meetings, record and issue meeting minutes, and perform many other tasks as required to ensure successful project delivery.

^[12]Some organizations will allow working clients to serve as IT project directors and even project managers. In the author's view, this is a mistake. Although the working client is essential to any IT project's success, contributing system requirements and business process expertise to the effort, very few working clients have experience in leading multitier IT projects, especially those involving outside technical contractors and consultants. Leave this work to an appropriately skilled IT manager, allowing working clients to contribute where they add greatest value in articulating and clarifying business requirements and system performance standards for the IT team.

< Day Day Up >