The Commitment Process

THE LEADERSHIP COMPONENT:

• Who is leading the project? _____

• Is that person the most appropriate responsible party to ensure success? _____

• Does the leader genuinely believe in the project and want it to succeed? _____

• Does the leader have the necessary skills for success?

  Demonstrates genuine respect for people throughout organization ____

  Listens well ____

  Demonstrates political savvy ____

  Possesses connections with others critical to the project's success ____

• Has project leadership been legitimized, as appropriate? ____

ORGANIZATIONAL LINKAGES:

• Has a compelling case for change been made? ____

• Has the case for change taken into consideration other changes already under way around the organization? ____

• Has the project team completed a stakeholder analysis, measuring the relative impact on stakeholders? ____

• Is there a clear and convincing linkage between the proposed project and the enterprise's strategy, goals, and objectives? ____

• Does this discussion include a consideration of the needs and concerns of long-standing members of the enterprise who may view proposed changes as a critique of past performance and contributions? ____

EXPECTATIONS:

• Has the project team diagnosed employee attitudes toward the proposed change? ____

• Will they participate in the change process? ____

• Has the team determined the optimal time for project kickoff? ____

• Has a clear message gone out to the enterprise concerning realistic project accomplishments? ____

• Has sufficient information about potential payoffs been disseminated so that employee expectations are high enough to ensure general involvement? ____

REWARDS:

• Have arrangements been made to reward participants for their

  Time? ____

  Ideas? ____

  Commitment? ____

• Has the project's impact on existing reward systems been analyzed ? _____

• Has the reward of participating

  Been recognized? ____

  Been taken into account for its impact on nonparticipants? _____

As you can see from this excerpt, preparing the enterprise for a truly transformational IT project is no trivial matter and requires the participation of the most senior layers of management to succeed. Although there may be a legion of other challenges facing the team, the absence of effective leadership in terms of organization change and business process reengineering can doom a large-scale IT project from the outset. As a next step in framing the team's commitment, the project leadership should define the business problem or opportunity driving the proposed investment of IT resources. This may seem a trivial activity, but it is surprising how disparate the initial conversation on this subject may become. It is essential that the team start from a common base of understanding about the project's rationale and purpose. To that same end, the author likes to walk project teams through the value template shown in Exhibit 7 so that everyone involved can appreciate the benefits of a positive delivery outcome.

Exhibit 7: Project Benefits Matrix

Avoid exaggeration. Remember that your chief financial officer (CFO) may view this document, and if you claim that the project's delivery will result in a major increase in revenue or a cost savings, the CFO will hold you and your line-of-business partners accountable for that positive impact to the bottom line. Few major IT projects save money, because they invariably incur added costs for the upkeep of the new systems that offset savings elsewhere. Furthermore, although IT may bear the cost of the new service, cost savings may come from the customer's side through business process changes over which IT has no influence. On the other hand, cost avoidance , risk mitigation, improved customer service, and even competitive advantage may all be positive attributes associated with your project. Think through the case for each benefit and justify it in the space provided on the form.

With a common view of the overall project vision and value in place, the time has come to detail project deliverables, including those that are essential for customer acceptance, those that are highly desirable if time and resources allow, and those that are optional (i.e., the project may be acceptably delivered without these components ). Next, indicate elements that are excluded from the scope of this project (but that may appear in future, separately funded phases of the project). This is a particularly important step. Do not hesitate to state the obvious. You will probably be amazed at what your customer assumes is included within your project's scope. By clearly stating what is in and what is not, you will avoid unpleasant surprises as your delivery date approaches. Some project deliverables may not be apparent to the team. For example, if your task is to replace the technology in a laboratory facility, you may not consider facilities alterations part of your mandate . Similarly, in delivering a software application to a business unit, you might easily overlook the desktop or information security implications of that change. To avoid such oversights, ask your PMO to develop checklists that your project teams may then regularly employ as part of their scoping exercises. ^[9]

Given the project's now agreed-upon deliverables, the team should assign critical success factors for customer satisfaction based upon the following vectors of measurement: scope, time, quality, and cost. These metrics must be defined in terms of the particular project. For example, if a project must be completed by a certain date (e.g., recent efforts to make systems year 2000-compliant), time rises to the top of the list. If time grows short, the enterprise will either adjust scope, sacrifice quality, or add to costs to meet the desired date. Similarly, if the scope of a project is paramount, its delivery date might be moved out to allow the team to complete the commitment. If time is also an important factor in delivery, more people could be added to the project to deliver it in scope and on time.

In a recent instance, the author was asked to develop an enterprise data mart for a business partner. The data elements, date of delivery, and resources allocated for the project were all fixed. However, the sponsor was willing to give on the quality of the data in the data store. He agreed that data cleanup would follow project delivery. As with many other aspects of the commitment process framework, the importance here is to ensure that a thoughtful discussion ensues and that issues are dealt with proactively rather than in a time of crisis. Obviously, the discussion of critical success factors must take place with the working client(s), creating a golden opportunity to set and manage customer expectations.

Because no major change to an IT environment is without implications, the commitment process must also identify any major impacts to other systems and services that will result from the implementation of the envisioned IT solution. For example, if a new application requires network infrastructure or desktop platform upgrades, these must be noted in the commitment document and their implications carried over more tangibly into the project plan and budget. Similarly, if a new information system requires the recoding of older systems or data extracts from enterprise systems of record, these impacts must be documented and factored into the project plan. As part of the analysis phase of your project, you must run these implications to ground and factor them into your plans. The sooner you catch them, the less costly they will be to your project. This area is one where the PMO team can be of considerable assistance. PMO staff are more likely to spot linkages among projects and the ripple effects of system and platform changes. Encourage them to employ their informal networks to ferret out the facts.

What often gets a project team in trouble is not what is documented but what goes unsaid. For this reason, the commitment process should require the team to explore project assumptions, constraints, and open issues. Because most IT professionals tend to be internal thinkers, this can be a formidable task. It therefore falls to the project's director or manager to draw out from the team and make explicit the inferred operating principles of the project, including the roles and responsibilities of project participants ( especially internal and external IT partner providers), how project activities should operate, what tools and technologies are to be employed, and how key business and technical decisions governing project outcomes will be made. All projects operate under the constraints of time-resource availability and dependency on the actions of others. For example, a particular project may be constrained by the unavailability of a particular technical specialist or by delays in the arrival of computer hardware and software. These factors may directly impact project outcomes but are out of the team's direct control. Make them explicit, so that the customer appreciates the risks to the project should they occur. Once they are made explicit, the project manager should track these issues to determine if and when they may adversely affect project outcomes . PMO staff can then work together to mitigate the associated risk, or at least to make it more visible to IT senior management and the affected project teams.

Open issues are different from constraints in that these elements can and will be addressed eventually by the project team. They appear in the commitment document to remind all those involved that if they remain open, these issues will adversely impact delivery. Thus, the open issues section of the commitment document is a parking lot for major follow-up items. Here, too, have the project manager oversee the list and ensure that all open items are closed in due course over the life of the project. The project manager or the project director should share the status of these items with the customer on a regular basis as part of initial expectation setting and subsequent project reporting.

The two remaining components of the commitment process are those elements that reflect project risks and those elements that itemize the project's specific resource commitments. Exhibit 8 shows an illustrative risk management matrix.

Exhibit 8: A Risk Management Matrix

In completing a commitment process, the project team should identify the major risks in pursuing the assignment. The table identifies risk categories and provides room for a more detailed description of a particular risk and its mitigation. For example, a project technology risk might entail introducing a new or untried technology into the enterprise's IT environment. A way to mitigate that risk would be to involve the vendor or some other experienced external partner provider in the initial installation and support of the technology. If the envisioned project solution requires clean data to succeed, the project plan could include a data cleanup process. If business requirements are not documented, the project could call for business analysis and process engineering work to get at those requirements. All in all, the team must be honest with itself and its customer in defining and dealing with project risks. Keeping risk statuses in the commitment process ensures that they remain visible and that those responsible are held accountable for their mitigation. Here again, the PMO's project manager will work in partnership with the project director to limit the undertaking's risk exposures.

The primary categories of IT project risk may be defined as follows: ^[10]

• Technology risk — the project calls for a new product or an untried technology supplier, a product with which the enterprise's IT organization has no expertise, or the untried integration of that product with other products already in place within the enterprise's IT environment

• Financial — the project is not sufficiently funded either for the initial deployment or in terms of ongoing operation and support of the implementation

• Security — the project possesses information security risks or exposes the enterprise's information assets to unwarranted access

• Data integrity — the existing quality of enterprise data could jeopardize the project, or the project's implementation could adversely impact the data integrity of other enterprise information systems

• Business continuity — failure to deliver the project will adversely impact the enterprise's ability to conduct business

• Regulatory — failure to complete the project jeopardizes the enterprise's regulatory situation, or delivery of the project may compromise the enterprise's regulatory situation

• Business requirements — the customer has not provided clear and complete project requirements

• Operational readiness — either the business unit or the IT organization is not prepared to operate the envisioned IT solution (e.g., there are no business processes in place; the staff needs training)

The project team, and in particular the project manager, must be attuned to any of these risks as they apply to the assignment, tracking and addressing these issues as need be. ^[11]

The document must indicate project resource needs in terms of people, time, and funding. Here, the tool allows for an optimistic set of best-in-class estimates; formal, planned estimates (i.e., expected outcomes as documented in the project plan); and contingency allowances. Although some projects come in ahead of schedule, more often than not, they come in late and at a higher cost than first estimated. Give your team some wiggle room by building in a realistic contingency. Bear in mind that although it is not a good practice to pad budgets and timelines , it is important to alert your customer to the reasonable dimensions of cost and time overruns that the project may experience.

From the standpoint of people, the document must explicitly name names and define roles and responsibilities (including the skills required). Exhibit 9 shows an illustrative list of project roles. The project director must ensure that a real person or people are assigned to each project role and that chosen IT staffers understand and agree to their assignments. See Exhibit 9. These commitments cannot occur without a delineation of the other two resource elements:

Exhibit 9: Roles and Responsibilities Matrix

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

• Skills, time, and duration of the commitment for each internal staff person

• Associated funding for hardware, software, contract labor, consulting, and so forth

These details will come from the project plan that accompanies and complements the commitment document. In the plan, activities are appropriately detailed, along with the duration and performer of each task. The plan tells each partner provider what is required of his or her team. It is the responsibility of these managers to ensure that they do not overcommit their own personnel. If the IT organization operates some sort of resource management database or tracking system, this may be easily accomplished. Otherwise , it rests with individual managers, as aided and abetted by the PMO, to keep things straight.

The commitment document is a key tool in project management process. Through its disciplined use, the team captures all the aspects of risk and ambiguity surrounding the envisioned project. It affords approaches to resource management and risk mitigation. Lastly, through the signoff process, the commitment document acts as a formal contract binding the players to their roles and responsibilities within the delivery process. During the course of delivery, things will change. Nevertheless, the commitment document serves as a point of reference, ensuring that all the key questions are raised at the initiation of a project and that the team, supported by the PMO, addresses all outstanding issues in due course. A number of other useful tools, most cited in the footnotes and housed in this book's accompanying Web site (http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991), can assist the project team in reaching a successful conclusion.

When viewed in its entirety, the commitment process leaves nothing to the imagination of the project team and those they serve. The commitment document makes explicit what is to be done, why the project merits resources, who is responsible for what, and what barriers lie in the path to success. The project plan details how team members will execute their respective assignments. Together, these documents form a contract that aligns resources and provides for a common understanding of next steps, roles, and responsibilities. The metrics for successful project delivery are few and simple: Did the project come in on time and within budget? Did it meet customer expectations? To answer these questions, simply run actual project results against the project's commitment document and plan.

This framework makes for a good beginning, but it does not ensure the success of the project. Being true to the commitment process addresses proactively many of the problems that might otherwise befall a project. Still, miscommunication and invalid assumptions can derail even the most effectively started projects. The concluding section of this chapter closes this gap by offering an approach to project performance measurement and reporting. Here, the PMO and its agents in the field — its project managers — hold the keys to success.

^[7] This section of Chapter 5 focuses on the commitment management process. The document for that process is templated in Appendix H and is also available in an electronic version. See The Hands-On Project Office , http://www.crc-press.com/e_products/downloads/download.asp?cat_no=AU1991, chpt5~5~commitment~template. For an example of the commitment document in use, chpt5~6~commitment~example.

^[8] The entire questionnaire is templated in Appendix F and is also available as an electronic form. See The Hands-On Project Office , http://www.crc-press.com/e_products/downloads/download.asp?cat_no=AU1991, chpt5~7~project leadership readiness~template.

^[9] See, for example, The Hands-On Project Office , http://www.crc-press.com/e_products/downloads/download.asp?cat_no=AU1991, chpt5~9~facilities project delivery~template, chpt5~10~Infrastructure Questionnaire for Projects~template, and chpt5~11~Security Questionnaire for Projects~template. In a similar vein, the following tool, originally developed by Pat Laughran, is a useful reminder of the pre-launch and launch steps for an information system or service; see The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt5~14~system launch checklist~template.

^[10] A more comprehensive risk management tool can be found in Appendix G and on the accompanying Web site. This tool allows the reader to rate and score the various risks associated with a particular IT project. When one is faced with options, the tool allows the reader to compare choices from the standpoint of risk management. See The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt5~8~risk management~template.