لطفا منتظر باشید ...
Project Features
One of the three elements of the project triangle is the project features and the quality of the project outcome. Underlying this element is the project requirements, which are derived from the project goals and objectives. The preceding chapters have detailed how important it is for a consensus on project goals and objectives to be arrived at early in the development process in order to set the proper course for the project. It is crucial that participants demonstrate an adequate understanding of overall project goals and objectives so as to minimize the problems created by the requirements changes that can result from initial misunderstandings of the project's direction. All the stakeholder groups must play a role in helping to define the desired systems boundaries for the project before further development work is undertaken. The ability to complete the project on time and within the estimated budgeted resources may be partly dependent on the clarity of the project goals/objectives, which shaped the definition of the systems boundaries. Some of the crucial factors affecting the chances for maximizing successful project outcomes are:Project requirements
Project audits
Senior management support
Project consultants
Project politics
We now focus on some of these issues to highlight the important role they play in the project triangle to maximize successful outcomes.
Project Requirements
Understanding the problem domain of the project is crucial to successful software development. However, it is important to recognize that the problem-definition process is an evolving one and that full comprehension, no matter how much effort is put into it, may remain elusive at the start of some particularly complex projects. Once a project has begun, clearer understanding is attained as subsequent layers of the problem domain are uncovered and other matters not thought of due to oversight or misunderstanding are forced into the mix of issues to be tackled. The users play a crucial role in determining the requirements for the project because of their understanding of the application problem domain. Still, with particularly complex projects, even the users' understanding of the problem domain may be limited and thus may give rise to periodic revisions during the development. Eventually changes to the project's requirements and systems functionalities may become necessary to reflect new insights into the application problem domain. The development team must tap the differing perceptions and orientations of the various user groups represented, in order to obtain broad perspectives on the requirements and functions of the system.The software requirements derived from the initial comprehension of the problem are bound to be modified in the course of the development. However, while requirements volatility is to be expected, controlling for the changes in the requirements becomes critical to successful project outcome. Not all aspects of the requirements that an evolving understanding of the problem domain uncovers should be allowed to factor into the current development effort. Some of the new requirements can be appropriately deferred to later enhancement efforts. Only the requirements changes that can be placed at the core of the system and its desired functionality, and that help clarify the team's understanding of the Chapters 3 and 8 have discussed in detail the nature of the failure factors, their impact on the software development process, and lessons organizations can learn from their own and others' past experiences with failed projects. Incorporating the lessons of past experiences into software development practices is critical to the success of the enterprise because it will minimize the likelihood of mistakes being repeated. Highly innovative software projects can and must be undertaken by organizations so long as such projects are not beyond their financial and technological capabilities.
Project Audits
Sound project management is critical to maximizing successful project outcomes. One of the tools available to project leaders is the use of regular audits to uncover problematic issues and/or error patterns with the potential to create problems later on. For example, the audits may be able to uncover emerging patterns of imbalance between the elements of the project triangle—that is, resources, features, and schedule—giving the project leader sufficient time to take corrective action. How the audits are carried out and who is entrusted with the responsibility (whether an internal or external auditor) is of no particular concern, as long as the integrity of the process and of the auditor are uncompromised. When that can be ensured, the results of the audit can be expected to provide valuable information to help in managing the project successfully. For large and complex projects, the audits must be frequent to ensure that potential problems are uncovered soon enough to be corrected. User feedback in such projects can also play an important role in the audit process. Active user participation and involvement in the audit may provide important information to the auditors on the progress being made, or lack thereof, on the desired systems functionalities in the project development. Thus, involving the diverse user communities and the development team in the audit may uncover potential sources of problems with the project.Keil and Robey (2001) describe cases where auditors fearing for their job security often preferred not to be the bearer of unpleasant—but constructive and potentially valuable—information on the status of the projects being audited. When project audit information is compromised to this extent, it renders the process useless. Auditors will only be able to do their job honestly and faithfully if they feel there is no perception of their being misconstrued as the bearer of bad news, or even worse, as outsiders because of the unique role they play in helping to uncover potential problems hidden within the many layers of the project. For projects where the vested interests of higher-ups in the organization are likely to challenge the work of the auditors, the intimidation factor alone may be enough to lead some auditors to shade the results so as to curry favor with those in senior management who may also be champions of the project. Escalation of senior management commitment to failing projects is often a combination of auditors failing to do their job honestly and/or project champions failing to heed whatever information auditors may provide regarding problems associated with the project. "Blowing the whistle on troubled software projects" can indeed amount to a courageous act, which some auditors would rather not carry out given the slightest hint that their superiors are unlikely to heed their warnings or are apt to blame them for the negative information (Keil and Robey 2001, 87).
Senior Management Support
Senior management's understanding of the project and its particular strategic value to the organization is also crucial to maximizing successful project outcomes. Such understanding should entail a high level of support and commitment to the development effort. The form the commitment and support take can be observed as elements of the project triangle impact each other. Senior management's understanding of the project and its strategic importance with respect to the organization's long-term prospects will influence their decisions on the project schedules, the resources needed to realistically meet the completion-time estimates, and the quality of the product that will be produced in the end. Such delicate balancing of decisions with significant import for the project cannot be deferred to anyone else in the organization. No one else in the organization possesses the kind of overall vision of the organization's strategic goals and objectives or has the authority and responsibility to realize them.However, senior management support and commitment, though extremely critical at times in resolving problems, must also be tempered with caution and guided by pragmatic realism. For example, if project information provided by a competent auditor shows trends that are not responsive to various corrective measures proposed and duly implemented, further escalation of that support and commitment will only lead to further unjustifiable expenditure of organizational resources. It is important that under such a scenario senior management take appropriate measures to deescalate their level of support and commitment in order to safeguard organizational resources. In essence, senior management should not be afraid to withdraw their support and commitment (undoubtedly spelling failure for the project) if such a decision is justified by all appropriate indicators provided by the project audits. Unrestrained support and commitment on the part of senior executives who are strong advocates or champions of a project often draw organizations into difficulties. The FoxMeyer Delta case discussed in the previous chapters is a poignant example of how overcommitment of senior management to a project can contribute to the bankruptcy of the company. Consequently, deescalation of senior management support and commitment to a troubled project should be welcomed and respected as indicative of their comprehension of the delicate balance among the elements of resources, features, and schedule that constitute the project triangle.In addition to the project audits, other sources must be developed or identified to provide additional confirmatory information to senior management. Multiple information sources and channels are essential to provide a level of redundancy to the system of information feedback between senior management and project teams (including project leadership), and to maximize the chance that senior management will stay informed about project status at all times. Multiple information channels will allow project-related problems and setbacks to be readily communicated upward to senior management and thus enable them to take corrective action to forestall further damage to the delicate balance of the project triangle. This type of bottom-up feedback information will not be achieved, however, if senior management is widely perceived on the project team to be "dictatorial" in their interactions with project team members. For example, whether decisions involving elements of the project triangle are arrived at by consultation or by executive fiat may signal to subordinate team members how to react to management on project-related problems—whether to be candid or to censor themselves.
Project Consultants
The use of consultants on projects is especially important in cases when the skill and experience levels of the members of the project team are judged inadequate or do not meet the requirements specifications of the project. The decision to engage the services of a consultant on a project must be made early in the course of the project development, soon after the requirements have been determined and the capabilities of the organization for undertaking it have been assessed to be inadequate to the task. The search for qualified and experienced consultants to join the project team, or if necessary to take over the entire development, must begin with thorough research on the background of potential candidates even before requests for proposals (RFPs) are sent out. The background research will help weed out qualified but inexperienced candidates and focus the search on those with the experience deemed relevant and appropriate to the requirements specifications. How the RFPs is written is also important in making sure only candidates with the requisite technical and technology experience and qualifications will respond. Well-written RFPs will save the organization valuable time as it reduces the number of unqualified and/or inexperienced candidates who respond.The selection process must begin soon after the deadline for the RFPs has passed. A thorough vetting of the proposals submitted must start with close attention being paid to the responses dealing with critical areas of the requirements specifications for the project. All claims made by the candidates in their responses to the RFPs must be thoroughly checked and independently verified for accuracy (something FoxMeyer Drug failed to do with Andersen Consulting on the Delta project). The strengths and weaknesses of each candidate vis--vis the project's requirements must be fully documented and thoroughly discussed in the meeting held to select the candidates. The time frame for deciding on the candidates should be set so the vetting of the candidates' RFP responses does not carry on for too long. It may be useful to develop a metric that can be used to rank order the candidates, when all the factors have been considered, before making the final selection. As much as feasible, the decision must be based on objective standards of what will be in the best interests of the organization and the project.The winning candidate should be invited to come and discuss the project, suggesting possible strategies for tackling it. If the organization is satisfied with the in-house presentation and discussion, the selection can be finalized with a contract detailing what the consultant's and organization's responsibilities will be on the project, and how the consultant's work will be monitored for adherence to the contract. Both parties must approve any changes to the contract before the changes are appended to the original contract.The writing of the contract will benefit from the services of an attorney who specializes in IT contracts. It is important for the organization to ensure that all important issues are clearly spelled out in the contract to protect the interests of both parties, especially those of the organization. Besides, it is good policy to ensure that the organization's and the consultant's liabilities in the agreement are spelled out to forestall any possible litigation resulting from termination of the agreement by either party. In addition, it is always important to have an escape clause dealing with noncompliance issues, so that in the event that the consultant fails to live up to the requirements provisions in the agreement, the organization can terminate the agreement and not have the project held hostage, as was the case with FoxMeyer's Delta project. A designated contact person must be selected from the consulting organization and the project organization to handle complaints and other matters related to the work on the project and to be a liaison to the other party. Typically in the project organization, the project leader or his or her designee can play that role. Projects may not succeed if the decision to engage the services of a consultant and the process used to select one are not handled properly, and if the work of the consultant on the project is not consistently monitored to ensure compliance with the terms of the agreement and performance expectations at all stages of the development process. In this regard, the work of the auditors will be important in ensuring that the consultants comply with the terms of the contract and make sufficient progress toward the desired project outcome.
Project Politics
Project development politics often begin in the selection process, when several projects may be competing for scarce organizational resources. Projects with powerful sponsors and/or champions may sometimes be selected for development over worthier ones with less powerful advocates. The stakeholders involved in the process of project selection often work behind the scenes to ensure that their choices are viewed more favorably by others, even if the objective merits of their project are not clear. Often the raw exercise of political power may be camouflaged by specious arguments purported to demonstrate the project's benefit to the entire organization. Organizational alliances may play a significant role in winning over others who might otherwise be opposed, or at least noncommittal, to the project(s) in question. Prioritizing projects for selection and development is thus a matter of the way organizational politics play out among competing stakeholders.Once the selection process is resolved, how development proceeds is to some extent controlled or influenced by a different set of political norms often dealing with project-triangulation issues—that is, the availability of adequate resources, the project features, and the schedule for completion. Here again powerful organizational interests may control the agenda unless senior executives step in and impose an organizationwide vision on the stakeholders. For example, the control of the requirements for the selected project(s) will be greatly influenced by the powerful interests of the stakeholder groups as each tries to influence the outcome in its favor. How the issue of requirements is resolved obviously has implications for both the resources needed to tackle the project and the time frame for completion. Therefore, project triangulation has substantial political undertones as each stakeholder group stakes a claim to its vision of what is in the overall organizational interests. For example, the technical personnel will present their vision of the requirements in terms of what they perceive or argue may be technically feasible, thus exerting control over what should be the accepted set of requirements for development. Similarly, the project sponsors and champions may view the requirements from a budgeting perspective, defining the decision as a resource-allocation issue. Finally, the users groups may try to influence the requirements from the perspective of what is in their best interests as potential users of the completed system. All of these competing stakeholder interests may seek to control the development outcome by pushing their particular agenda. Sometimes consensus may be arrived at through the interaction process, which may serve the overall organizational interests. But more often the most powerful stakeholder group—and this may vary from project to project within a particular organizational context—carries the day, whether the resource controllers, the controllers of the systems functionalities, or the controllers of the technological dimensions. Thus the stakeholder-interaction model described here as played out in the project triangle reflects to some extent the power relationships that often exist in the context of systems development (Sillince and Mouakket 1997).How power is shared among stakeholders on the project to match individual and/or group responsibilities and accountability is important in ensuring successful outcomes. Regardless of the power distribution and decision-making centers on the project, communication channels among all stakeholders, from the top to the bottom, must always be open, free, and unencumbered to allow for the free exchange of ideas and the sharing of information to guarantee smooth cooperation on the project. Also, allowing for free and open access to communication channels among project stakeholders has its own benefits, as discussed earlier. For example, it makes possible quick airing and resolution of potential problems and conflicts. It will allow for control of requirements volatility even as the loci of power and decision making change with the changes in the makeup of the project stakeholders. Free and open communication also creates an operating environment where superordinate decision makers are encouraged to act in a consultative manner and are less inclined to be coercive or dictatorial in relating to subordinates on the project. Subordinate stakeholders are also less likely to be inclined to censure themselves by filtering out bad news on a project before communicating their findings upward because of their perception of how their superordinates will react to them. The support and commitment of individual stakeholders on the project may be inversely proportional to their perceived power to act, and may also reflect their perceptions of responsibility and expectations of accountability on the project team. The focus in decision-making contexts will always invariably be on maintaining the correct equilibrium among the three elements of the project triangle. Thus stakeholders will be less inclined to accept changes in the requirements, for example, since such changes could significantly impact the features or functionality of the system, which could in turn significantly alter the schedule and the resources needed to achieve it.
