DEALING WITH THE CULTURAL ISSUES
Considerations about moving to an IT project development incentive program should include careful thought about the cultural issues involved in making the transition.
Going to this new approach means change. Whenever change is introduced within an organization, it brings out issues that will have to be recognized and resolved. Many of the issues associated with a new compensation approach to the development of IT
applications projects have been identified in this portfolio. That is not to imply that additional issues will not arise; every culture is different and each presents its set of unique concerns.
The salient concern, relative to the cultural changes involved, is to develop an awareness that they will create some level of discord and that as they arise, they need to be addressed. Those concerns that are raised should be given a fair hearing and carefully considered. Much of what is going to be done here will probably be new to the organization, and as such it should be recognized that it will require time and some adjustments to come to a sound approach.
One of the cultural issues certain to arise is that of the fairness of providing people working on IT development projects an opportunity to earn additional income. This is going to have to be explained within the context of why they are being given additional consideration for what might be considered “normal” work. One way to address this issue is to explain the benefits that are going to accrue to the organization if the plan is put in place and it succeeds. Another way to help this situation is to develop a process that will, if the plan proves workable and is adopted, allow others an opportunity to join projects in the future.
As has been indicated, an underlying issue with the plan is that the project team, in order to obtain the additional income, is going to have to put forth extra effort to meet its goals. As people come to understand that getting the additional payments requires extra effort — in some cases, considerable extra effort — some of them are going to lose interest in becoming involved.
There will be some element of inherent unfairness in moving to a compensation incentive program. However, if doing so makes good business sense, the plan should be put in place. The difficulties associated with some level of employee discontent at the onset are going to be more than overcome by the eventual success of the process.
An important key to dealing with the cultural issues is for management to be as candid and as fair about the process as possible. When disagreements arise, if the managers are willing to take people through the logic of the plan and answer any and all questions as fully as possible, they will have discharged their responsibility.
At that point, the onus for accepting or rejecting the process resides with the employee.
CONCLUSION
If the correct environment is developed, the right people are chosen to participate, and the compensation incentive plan is well- managed, it can produce benefits (perhaps significant benefits) for the entire organization. Putting the plan in place, overcoming whatever difficulties may arise, and documenting the result will take time and patience. Several versions of the process might have to be tried to find the best approach for a particular organization.
The potential payoffs within the plan: improving the quality of IT projects, bringing those projects to completion on time, and within the original budget, should be seen as of paramount importance to the IT department and to the organization. Achieving those rewards is worth the effort required. They are also worth enduring any cultural strains that may have to be faced and overcome in order to reach the desired goals.
The subject of changing IT development project compensation should be considered on the basis of risk versus reward. Using that approach, a favorable argument can be quickly developed that balancing the risk (the approach fails) against the reward (significant improvements in IT project management), there is no reason not to move to a changed compensation plan. New ways must be found to improve the IT
project development process; going to a new compensation approach represents a sound way to move toward that improved environment.
Chapter 34: The Pitfalls of Client/Server
Development Projects
Paul Cullen
OVERVIEW
The management of client/server projects involves unique pitfalls within traditional systems development categories. This chapter addresses the unique characteristics of client/server development projects within the following categories:
§ Defining/documenting business requirements
§ Determining hardware/software/network requirements
§ Estimating
§ Project tracking
§ Defining tasks
§ Estimating hours required
§ Estimating percentage of completion
§ Timekeeping
§ Issue tracking
§ Developing skills with technology and tools
§ Security
§ Testing/QA process
§ Developing documentation
§ Organizational stability
§ Prototyping/usability
§ Sign-offs and approval
DEFINING AND DOCUMENTING BUSINESS
REQUIREMENTS
As with a traditional development project, documenting requirements should be the start of a client/server development project. It is here that the user requirements are defined as a basis for the project estimate and cost benefit analysis. The requirements document should be detailed and include input screens, processing cycles, and output reports. The database design should also be included, defining data relationships. Not only is defining/documenting business requirements important for estimating the initial effort of the project, it is also critical for
determining changes in scope and determining what “done” is. Many times what is casually reviewed at the start of a project becomes critically important in determining a project’
s completion. Typical elements of a requirements document
include:
§ Objective of the project/system
§ Business requirements
§ Input/output requirements
§ Affected business area
§ Processing requirements
§ Security requirements
§ Data or file handling requirements
§ Organizational impacts
§ Documentation requirements
It is difficult for an auditor to determine if the all requirements are comprehensive and adequately defined. However, at a minimum, the auditor should verify that the requirements are defined at a sufficient level of detail and that there is appropriate user management authorization.
DETERMINING HARDWARE, SOFTWARE, AND NETWORK
REQUIREMENTS
Once user requirements are defined, hardware/software/network requirements can be established. These requirements are used to determine the processing platform and networking for the system. Factors that determine the appropriate platform(s) are existing/strategic network infrastructure, number of concurrent users, size of the database, and volume of transactions. There is typically no “right” platform to use and many IS personnel have differing opinions. In addition, vendors are always announcing new releases with new features, making it difficult to distinguish existing product features versus vaporware. Beware of technologies and methodologies that introduce new terms and vernaculars that provide a smoke screen for poor project management and lack of expertise. Hopefully, a best approach is chosen considering cost, systems performance, and ease of development. Typically, the requirements are documented in an architecture document that include:
§ Business requirements
§ Tactical considerations
§ Strategic considerations
§ Interfaces with other systems
No one hardware/software platform will “fit” all applications, just as a hammer alone will not build a house. However, no small part of the platform choice should be what
platforms the developers are familiar with. Familiarity with the platforms chosen will improve the accuracy of the estimates and help ensure that “system killer” problems will not be encountered later. It is too risky to use unproven technologies as a platform for large development projects.
A potential bottleneck with client/server systems is the network capacity and traffic between the user workstation and the server. Many times, these systems are expected to perform over wide area networks (WANs) that may not provide consistent network response times.
ESTIMATING
One use of the project estimate is to determine whether management wants to fund the project based on a cost/benefit analysis. Obviously, if the estimates are not accurate, management cannot make good decisions on whether they want to do the project, assign people to tasks, or plan on when deliverables will be available.
Essentially, without goods estimates, project managers cannot manage. Factors that go into good estimates are:
§ Experience with the hardware/software/network/development tools: If the developers are not experienced with the platforms/tools, management should realize that the estimate is probably not very good and be ready to spend much more on the project and expect delays.
§ Familiarity with the requirements: Were the developers involved in the requirements definition? If not, again the estimate is probably not very good; and be ready to spend much more on the project and expect delays.
§ Existing systems: Is the new application a rewrite of existing systems where the reports and data requirements are defined? If so, the estimate may be pretty accurate. Otherwise, additional effort may be required to re-do the system to meet user requirements.
Hopefully, a track record of similar development efforts can be used to provide a reality check for the estimates. This can also be used as a control for managing developers who may be padding their estimates. A confidence factor or range should be a part of this estimate. This would give management a best-case and worst-case scenario. This would allow management the ability to decide not to do the project if it might be too expensive or likely not meet deadlines. A final pitfall to watch out for is a target date set by senior management to be committed to by the project team. If a top-down target date is set, there is pressure on the development staff to “back into”