The Commitment Process

 < Day Day Up > 



Initial project scoping is key to the subsequent steps in any project management process. All too often, projects are pursued without a clear understanding of the associated risks and resource commitments, leaving both the working clients and the project team exposed to the uncontemplated twists and turns of project execution and without a constructive understanding of their respective roles and responsibilities. Similarly, sometimes the most important information in framing an IT project — including the team's operating assumptions, the project's dependencies, and the customer's measures of success — is left undocumented and remains a topic of only brief conversation. If the various handoffs among team players also go unarticulated, these matters leave process participants without a clear sense of the process workflow and their respective responsibilities. Any of these traits can spell disaster for the project team and its project delivery efforts.

To avoid these and other contributors to delivery problems, IT project teams should embrace a commitment process that ensures a well informed basis for action. A framework for commitment management follows. [7] Like the other illustrations in this volume, this methodology's application should be balanced against the needs of the occasion. For example, if the project in question covers well trodden ground, less rigor is required than if the envisioned project blazes trails into hitherto unexplored territories. The commitment management process itself forces the project team to ask the very questions that will help it to determine the best course of action. This framework and checklist also ensure that the team addresses all the elements of risk and uncertainty surrounding the envisioned project.

From the outset, no project should proceed without an executive (business) sponsor, at least one working client, and an identifiable source of funding. The executive sponsor's role is to ensure the financial and political support to see the project through to completion. He or she owns the result and is therefore the project's most senior advocate. If the project in question happens to be sponsored by the IT organization itself, the chief IT executive will serve as its sponsor, and the IT manager who will own the system or service once it is in production will act as the working client. As mentioned earlier, working clients operate as the liaisons and day-to-day project team members from the line-of-business side of the house. They bring intimate knowledge of the business requirements driving the project, as well as a detailed understanding of the role that IT enablement will play within their business units. Lastly, the sponsor and the working clients must bring to the table the resources required for project delivery, including the funding for hardware and software purchases, hiring external consultants and contracts, and if appropriate, paying the IT organization for its participation. Note that I take it as a given that the planning process has approved the project in question for consideration by IT.

With these prerequisites in place, the project leadership — typically the project director, the project manager, the working clients, and technical subject-matter experts — will define the scope of the project. The first thing for the team to ask itself is, "Do we know enough about the project at hand to define its parameters confidently, including the risks involved, time and cost requirements, the skills required, and the technologies to be employed?" Remember that your team must commit to the project at some point. It should not do so unless it has a clear sense of what is involved operationally and technically to meet the customer's requirements. If, for example, the project is one with which the team has had experience, team members may come to the table with some confidence. But if they are treading on new ground, my recommendation is that they "chunk" the project, starting with an analysis phase. The outcome of such a first step would be to establish the knowledge to create a solid set of customer requirements, a thorough risk analysis, a project plan, and a budget for the remaining phases of the project. With this information in hand, the team is now positioned to commit to the actual delivery of an IT solution. By drawing on past experiences and by exercising due diligence up front, the project team will find itself in a much stronger position from the outset to manage customer expectations and to mitigate project risks.

Many IT projects are routine, but some are transformational. Anyone who has had the dubious honor of leading the implementation of an enterprise resource planning (ERP) system, such as PeopleSoft, Oracle, or SAP, knows exactly what I am talking about. Here, the scope of the project touches most key aspects of the business and requires major process change across the enterprise to have the desired impact on corporate performance. In this context, project leadership takes on a whole new meaning. Before entering into such an assignment, business and IT executive managers must ask themselves, "Have we prepared the organization for the degree of change driven by this commitment to information technology? Do we have the right people in place to lead the change process?" and so forth. From these considerations will emerge any number of more granular issues, as illustrated in part by Exhibit 6. [8]

Exhibit 6: Project Leadership Questions — An Excerpt

start example

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? _____

end example

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

start example

Business Improvement

Major

Minor

None

Business Value Statement (in Support of the Improvement)

Increase revenue

_____

_____

_____

_______________

Decrease cost

_____

_____

_____

_______________

Avoid cost

_____

_____

_____

_______________

Increase productivity

_____

_____

_____

_______________

Improve time-to-market

_____

_____

_____

_______________

Improve customer service/value

_____

_____

_____

_______________

Provide competitive advantage

_____

_____

_____

_______________

Reduce risk

_____

_____

_____

_______________

Improve quality

_____

_____

_____

_______________

Other (describe)

_____

_____

_____

_______________

end example

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

start example

Potential Risk

Description of Risk

Resolution

Technology

_______________

________

Financial

_______________

________

Security

_______________

________

Data integrity

_______________

________

Business continuity

_______________

________

Regulatory

_______________

________

Business requirements

_______________

________

Operational readiness

_______________

________

Other (explain)

_______________

________

end example

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

start example

Role

Name of Associate

Responsibility

The Core Project Team:

Executive Sponsor

__________

_______________

Working Client(s)

__________

_______________

Project Director

__________

_______________

Project Manager

__________

_______________

Business Analyst

__________

_______________

Application Lead

__________

_______________

Systems Lead

__________

_______________

Data Management Lead

__________

_______________

Infrastructure Lead

__________

_______________

Customer Services Lead

__________

_______________

Internal and External Partners:

Vendor-based Project Management Support

__________

_______________

Technical Architect(s)

__________

_______________

Business Process Architect(s)

__________

_______________

Creative Development/UI

__________

_______________

Development

__________

_______________

Training/Documentation

__________

_______________

QA/Testing

__________

_______________

Infrastructure

__________

_______________

Security

__________

_______________

Other Partner Provider(s) - Hardware/Software:

end example

  • 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.

[11]The accompanying tracking tool will help organize project issues and risks as they arise. See The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt5~12~Project Issues and Action Items~template, and chpt5~13~Project Issues and Action Items~example.



 < Day Day Up > 



The Hands-On Project Office(c) Guaranteeing ROI and On-Time Delivery
E-Commerce Security: Advice from Experts (IT Solutions series)
ISBN: N/A
EAN: 2147483647
Year: 2006
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net